Field
Embodiments of the present disclosure generally relate to software-defined networking (SDN). In particular, embodiments of the present disclosure relate to an SDN switch configured to provide application-based, conditional forwarding and load balancing (flow forwarding).
Description of the Related Art
Global Internet Protocol (IP) traffic has increased fivefold in the last five years, and is expected to increase another threefold over the next five years. As the number of mobile devices and other IP devices connecting to the Internet are growing rapidly, data traffic that needs to be monitored and inspected by network security devices is also increasing. Such increasing data traffic from different types of devices is creating new vulnerabilities that need to be monitored/inspected and controlled by the network security devices. As new types of network security issues are emerging, network security devices also need to include new policy rules to monitor and control data traffic to/from a secured network. It is becoming difficult for hardware-based switches or network security devices to provide the required scalability for rapidly increasing data traffic and increasing policy rules. To overcome the limitations of existing hardware-based switches or network security devices, which lack the flexibility of incorporating new and different forwarding rules, SDN devices that allow updates at regular intervals have been proposed for providing scalable and fast processing of network packets.
With such features, typical SDN devices, e.g., SDN switches, are moving to replace, and are being configured to work in conjunction with traditional routers and switches in several high-end applications including the emerging cloud and datacenter environments where high volumes of traffic need to be monitored and filtered. SDN is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. This is done by decoupling the operating system that makes decisions about where the traffic is sent (the control plane) from underlying hardware systems that forward traffic to the selected destinations (the data plane).
One aspect of SDN is the separation or abstraction of the control plane from the data plane. A typical enterprise network device may have a controlling element, and a forwarding element within the same box that implements the SDN features. The forwarding elements are configured to receive packets, do conversion(s) if required, and forward the packets to their respective destinations based on instructions received from the controlling elements. In implementation, forwarding elements (also referred to as the data plane) receive forwarding commands from the control plane (also referred to as the controller) where the forwarding elements make the forwarding decision to be implemented in the data plane. The control plane is typically a collection of software running within a router or within a switch that uses one or more rule sets to identify the packet(s) received from traffic, decide appropriate actions to be taken on the packet(s), and convey the actions/decisions to the data plane so the data plane knows where to forward the packet(s).
To allow communications between different network devices or SDN devices, the OpenFlow protocols, including, but not limited to Open Networking Foundation (ONF), “OpenFlow Switch Specification,” Version 1.5.0 (Protocol version 0x06), Dec. 19, 2014 (hereafter, the “OpenFlow Protocol”), are now being used. The OpenFlow Protocol is hereby incorporated by reference in its entirety for all purposes. The OpenFlow Protocol intends to provide access to the data plane of a network device or an SDN device to other network devices and/or SDN devices in addition to providing a protocol for device configuration. The OpenFlow standard was defined to increase flexibility and programmability of networks/network devices in order to allow network administrators to more easily tailor network configurations to their needs. The OpenFlow Protocol requires an SDN switch to contain a series of associative flow tables, wherein each entry in a flow table may contain ternary values for a desired selection of packet fields (e.g., Media Access Control (MAC) source and destination addresses, IP source and destination addresses, Transmission Control Protocol (TCP) port numbers and the like). The OpenFlow Protocol defines a number of standardized packet header fields for matching as well as allowing users to add their own custom fields. Table entries are in prioritized order, and for each individual packet to be processed by the SDN switch, the table entries are searched for a matching entry. Note that, the table entries can have ternary values to match a broad selection of packets. When the first matching table entry is found within the flow table, a set of actions associated with the matching flow table entry can be executed. Such actions may modify the fields of the packet, for example, by setting the MAC destination field to a new value, and may also direct the SDN switch to output the packet to a particular switch port in a particular queue, or send it to an SDN software controller, or drop the packet. It is generally intended that when the existing flow tables do not contain a matching flow table entry, the packet is sent to the controller, which may respond by installing rules within the switch to properly process subsequently received similar packets. This accomplishes the goal of control plane and data plane separation by having the SDN controller software make the decisions concerning what flow tables are to be installed, whereas the SDN switch simply follows the directives of the controller instead of making complex behavioral decisions on its own. In general, existing SDN switches are configured to be able to flexibly match against packets, and directed by the matches, perform a comprehensive set of actions to modify the packet and decide what to do with it.
SDN architectures that use the OpenFlow Protocols provide a high degree of dynamic flexibility to define new rules to be used, and actions to be taken by the network security devices. SDN architectures that use the OpenFlow Protocol lead to adaptation of more flexible system hardware architecture and implementation to enable quick turnkey solutions for concurrent deployment of various types of network applications.
While SDN architectures have addressed various limitations in the art, existing SDN architectures remain inadequate in relation to flexibly dealing with traffic volume that the SDN controller and attached SDN switches can handle. Data flow in a network may be related to/associated with different types of applications, and therefore data flow needs to be differentially treated by the SDN switches and/or network security devices. Ideally, traffic received by the SDN controller should be forwarded conditionally to one or more switches based on the application associated with the data flow or data packet. For efficient utilization of the SDN switches and/or network security devices, it is also desirable for the load on different SDN switches and/or network security devices to be distributed substantially evenly. The SDN controller should also be able to transfer load from one switch to another, or from one port to another without disturbing the established session integrity.